A public key infrastructure (PKI) provides a set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption. Traditionally, communications between computers has been secured using Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), which rely on certificate authority (CA) based PKIs, such as X.509 PKIs. In such CA-based PKIs, a certificate authority issues digital certificates certifying the ownership of public keys by the named subjects of the certificates. Typically, the CA keeps its root private key secret while publishing its root public key, which is also referred to as the root certificate. Modern operating systems (OS) often maintain a list of such root certificates. Further, the actual root private/public keys need not be used, as the CA may instead generate and use intermediate private/public keys for security reasons. To authenticate one entity to another, such as a website to a web browser, the CA generates a certificate by binding a public key of the entity (e.g., Wikipedia's public key) with an ID of the entity (e.g., *.wikipedia.org) using the CA's root private key via a digital signature algorithm. The other entity, e.g., the web browser, can then verify such a certificate provided by the first entity using the CA's root certificate that was published.
“Internet of things” (IoT) is used to refer to the internetworking of physical devices, vehicles, buildings, and other objects that are embedded with electronics, software, sensors, actuators, and the like, and that have network connectivity allowing the IoT devices to collect and exchange data. Like traditional authentication between computers, IoT devices also require security functions such as authentication, confidentiality, integrity, and non-repudiation. For example, privacy-sensitive messages exchanged in IoT applications need to be encrypted and must not be altered in an unauthorized manner. In addition, data centers (e.g., that collect information from IoT devices) or IoT gateways need to be able to verify the identity of IoT devices. In some cases, IoT devices must not be able to deny having sent messages for accountability reasons.
A traditional CA can issue certificates to IoT devices for use in authentication. However, traditional CAs present a single-point-of-failure, as the CA itself can be compromised, requiring all certificates signed by the CA's private key to be regenerated and re-inserted into the IoT devices. Installing such new certificates into IoT devices after they are deployed can be very difficult, especially as many IoT devices do not have input/output devices such as keyboards or monitors. Further, manufacturers (rather than device owners) typically install certificates in IoT devices by generating a private/public key pair, sending the public key and the device's ID to a CA, receiving a certificate (which is the public key signed with the CA's private key) from the CA, and installing the certificate on the IoT device. However, this means the manufacturer of an IoT device knows the IoT device's private key, which can be leaked by, e.g., hacking the manufacturer's server. A leaked private key of an IoT device also must be revoked, which is typically handled by maintaining “certificate revocation lists (CRLs)” at the CA and using Open Certification Status Protocol (OCSP) responders to respond to requests indicating whether particular certificates are revoked or not. However, the OCSP may not always respond (e.g., it may not respond due to a distributed denial of service (DDoS) attack), and revoked certificates may still be accepted when an OSCP does not respond. In addition, the process of checking whether a certificate is revoked has a high verification overhead involving a number of initial signature verifications (three to be exact) by the requestor, one round trip between the requestor and the OSCP, time for look-up in the OSCP, one signature generation by the OSCP, and two additional signature verifications by the requestor.